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1 "Systems and Methods for Generating Visual 

2 Representations of Graphical Data and Digital 

3 Document Processing" 

4 

5 Field of the Invention 

6 

7 The invention relates to data processing 

8 methods and systems. More particularly, the 

9 invention relates to methods and systems for 

10 processing "graphical data" and "digital documents" 

11 (as defined herein) and to devices incorporating 

12 such methods and systems. In general terms, the 

13 invention is concerned with generating output 

14 representations of source data and documents; e.g. 
PJ 15 as a visual display or as hardcopy. 

W 17 Background to the Invention 

r 18 

19 As used herein, the terms "graphical data", 

20 "graphical object" and "digital document" are used 

21 to describe a digital representation of any type of 

22 data processed by a data processing system which is 

23 intended, ultimately, to be output in some form, in 

24 whole or in part, to a human user, typically by 

25 being displayed or reproduced visually (e.g. by 

26 means of a visual display unit or printer) , or by 

27 text-to-speech conversion, etc. Such data, objects 

28 and documents may include any features capable of 

29 representation, including but not limited to the 

30 following: text; graphical images; animated 

31 graphical images; full motion video images; 

32 interactive icons, buttons, menus or hyperlinks. A 
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1 digital document may also include non-visual 

2 elements such as audio (sound) elements. A digital 

3 document generally includes or consists of graphical 

4 data and/or at least one graphical object. 
5 

6 Data processing systems, such as personal 

7 computer systems, are typically required to process 

8 "digital documents", which may originate from any 

9 one of a number of local or remote sources and which 

10 may exist in any one of a wide variety of data 

11 formats ("file formats"). In order to generate an 

12 output version of the document, whether as a visual 

13 display or printed copy, for example, it is 

14 necessary for the computer system to interpret the 

15 original data file and to generate an output 

16 compatible with the relevant output device (e.g. 

17 monitor, or other visual display device, or 

18 printer) . In general, this process will involve an 

19 application program adapted to interpret the data 

20 file, the operating system of the computer, a 

21 software "driver" specific to the desired output 

22 device and, in some cases (particularly for monitors 

23 or other visual display units) , additional hardware 

24 in the form of an expansion card. 
25 

26 This conventional approach to the processing of 

27 digital documents in order to generate an output is 

28 inefficient in terms of hardware resources, software 

29 overheads and processing time, and is completely 

30 unsuitable for low power, portable data processing 

31 systems, including wireless telecommunication 

32 systems, or for low cost data processing systems 



such as network terminals, etc. Other problems are 
encountered in conventional digital document 
processing systems, including the need to configure 
multiple system components (including both hardware 
and software components) to interact in the desired 
manner, and inconsistencies in the processing of 
identical source material by different systems (e.g. 
differences in formatting, colour reproduction, 
etc) . In addition, the conventional approach to 
digital document processing is unable to exploit the 
commonality and/or re-usability of file format 
components . 

Summary of the Invention 

It is an object of the present invention to 
provide methods and systems for processing graphical 
data, graphical objects and digital documents, and 
devices incorporating such methods and systems, 
which obviate or mitigate the aforesaid 
disadvantages of conventional methods and systems. 

The invention, in its various aspects, is 
defined in the Claims appended hereto. Further 
aspects and features of the invention will be 
apparent from the following description. 

In a first aspect, the invention relates to a 
method of redrawing a visual display of graphical 
data whereby a current display is replaced by an 
updated display, comprising, in response to a redraw 
request, immediately replacing the current display 



1 with a first approximate representation of the 

2 updated display, generating a final updated display, 

3 and replacing the approximate representation with 

4 the final updated display. 
5 

6 In a second aspect, the invention relates to a 

7 method of generating variable visual representations 

8 of graphical data, comprising dividing said 

9 graphical data into a plurality of bitmap tiles of 

10 fixed, predetermined size, storing said tiles in an 

11 indexed array and assembling a required visual 

12 representation of said graphical data from a 
q 13 selected set of said tiles. 

yj 15 The methods of said second aspect may be 

fJI 

I*? 16 employed in methods of the first aspect. 

is . 17 

5 18 A third aspect of the invention relates to a 

19 method of processing a digital document, said 

p; 2 0 document comprising a plurality of graphical objects 

K 21 arranged on at least one page, comprising dividing 

H ; 22 said document into a plurality of zones and, for 

23 each zone, generating a list of objects contained 

24 within and overlapping said zone. 
25 

2 6 The methods of the second aspect may be 

27 employed in the methods of the third aspect. 
28 

29 In accordance with a fourth aspect of the 

30 invention, there is provided a digital document 

31 processing system adapted to implement the methods 

32 of any of the first to third aspects. 
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2 A preferred system in accordance with the 

3 fourth aspect of the invention comprises: 

4 an input mechanism for receiving an input 

5 bytestream representing source data in one of a 

6 plurality of predetermined data formats; 

7 an interpreting mechanism for interpreting said 

8 bytestream; 

9 a converting mechanism for converting 

10 interpreted content from said bytestream into an 

11 internal representation data format; and 

12 a processing mechanism for processing said 
jp 13 internal representation data so as to generate 

14 output representation data adapted to drive an 

UJ 15 output device. 

£ 16 

17 In a further aspect, the invention relates to a 

s 18 graphical user interface for a data processing 

^r; 19 system in which interactive visual displays employed 

H 20 by the user interface are generated by means of a 

J** 21 digital document processing system in accordance 

22 with the fourth aspect of the invention and to data 

23 processing systems incorporating such a graphical 

24 user interface. 
25 

26 In still further aspects, the invention relates 

27 to various types of device incorporating a digital 

28 document processing system in accordance with the 
2 9 fourth aspect of the invention, including hardware 

30 devices, data processing systems and peripheral 

31 devices. 
32 



1 Embodiments of the invention will now be 

2 described, by way of example only, with reference to 

3 the accompanying drawings. 
4 

5 Brief Description of the Drawings 

6 

7 Fig. 1 is a block diagram illustrating an 

8 embodiment of a preferred digital document 

9 processing system which may be employed in 

10 implementing various aspects of the present 

11 invention; 
12 

p 13 Fig. 2A is a flow diagram illustrating a first 

14 embodiment of a first aspect of the present 

yj 15 invention; 

JE 16 

17 Fig. 2B is a flow diagram illustrating a second 

9 18 embodiment of a first aspect of the present 

y 19 invention; 

2 0 

01 

fi 21 Fig. 3 is a diagram illustrating a method of 

H w 22 scaling a bitmap in a preferred embodiment of the 

23 first aspect of the invention; 

24 

25 Fig. 4A is a diagram illustrating a 

26 conventional method of using an off-screen buffer 

27 for panning a visual display of a digital document; 
28 

29 Fig. 4B is a diagram illustrating a method of 

30 using an off-screen buffer for panning a visual 

31 display of a digital document in accordance with a 

32 second aspect of the present invention; 
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1 

2 Fig. 5A is a diagram illustrating memory 

3 allocation and fragmentation associated with the 

4 conventional method of Fig. 4A; 
5 

6 Fig. 5B is a diagram illustrating memory 

7 allocation and fragmentation associated with the 

8 method of Fig. 4B; 
9 

10 Fig. 5C is a diagram illustrating a preferred 

11 method of implementing the method of Fig. 4B. 
12 

13 Fig. 6 is a diagram illustrating the use of 

14 multiple parallel processor modules for implementing 

15 the method of Fig. 4B; and 
16 

17 Figs. 7 and 8 are diagrams illustrating a 

18 method of processing a digital document in 

19 accordance with a third aspect of the invention. 
20 

21 Detailed Description of the Preferred Embodiments 

22 

23 Referring now to the drawings , Fig. 1 

24 illustrates a preferred digital document processing 

25 system 8 in which the methods of the various aspects 
2 6 of the present invention may be implemented. Before 

27 describing the methods of the invention in detail, 

28 the system 8 will first be described by way of 

29 background. It will be understood that the methods 

30 of the present invention may be implemented in 

31 processing systems other than the system 8 as 

32 described herein. 
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2 In general terms, the system 8 will process one 

3 or more source documents 10 comprising data files in 

4 known formats. The input to the system 8 is a 

5 bytestream comprising the content of the source 

6 document. An input module 11 identifies the file 

7 format of the source document on the basis of any 

8 one of a variety of criteria, such as an explicit 

9 file-type identification within the document, from 

10 the file name (particularly the file name 

11 extension) , or from known characteristics of the 

12 content of particular file types. The bytestream is 

13 input to a "document agent" 12, specific to the file 



Jf 14 format of the source document. The document agent 12 

iy 15 is adapted to interpret the incoming bytestream and 

ill 

%i 16 to convert it into a standard format employed by the 

Rl 17 system 8, resulting in an internal representation 14 

g 18 of the source data in a "native" format suitable for 

y 19 processing by the system 8. The system 8 will 

y* 20 generally include a plurality of different document 

%1 21 agents 12, each adapted to process one of a 

H* 22 corresponding plurality of predetermined file 

23 formats. 

24 

25 The system 8 may also be applied to input 

2 6 received from an input device such as a digital 

27 camera or scanner. In this case the input 

28 bytestream may originate directly from the input 
2 9 device, rather than from a "source document" as 

30 such. However, the input bytestream will still be 

31 in a predictable data format suitable for processing 

32 by the system and, for the purposes of the system, 



1 input received from such an input device may be 

2 regarded as a "source document". 

3 

4 The document agent 12 employs a library 16 of 

5 standard objects to generate the internal 

6 representation 14, which describes the content of 

7 the source document in terms of a collection of 

8 generic objects whose types are as defined in the 

9 library 16, together with parameters defining the 

10 properties of specific instances of the various 

11 generic objects within the document. It will be 

12 understood that the internal representation may be 
^ 13 saved/stored in a file format native to the system 
W 14 and that the range of possible source documents 10 
yj 15 input to the system 8 may include documents in the 
%1 16 system 1 s native file format. It is also possible 

03 17 for the internal representation 14 to be converted 

W 

18 into any of a range of other file formats if 

O 19 required, using suitable conversion agents (not 

14 . 20 shown) . 

jM. 22 The generic objects employed in the internal 

23 representation 14 will typically include: text, 

24 bitmap graphics and vector graphics (which may or 

25 may not be animated and which may be two- or three- 

26 dimensional) , video, audio, and a variety of types 

27 of interactive object such as buttons and icons. 

28 The parameters defining specific instances of 

29 generic objects will generally include dimensional 

30 co-ordinates defining the physical shape, size and 

31 location of the object and any relevant temporal 

32 data for defining objects whose properties vary with 



10 

■r 

1 time (allowing the system to deal with dynamic 

2 document structures and/or display functions) . For 

3 text objects, the parameters will normally also 

4 include a font and size to be applied to a character 

5 string. Object parameters may also define other 

6 properties, such as transparency. 
7 

8 The format of the internal representation 14 

9 separates the "structure" (or "layout") of the 

10 documents, as described by the object types and 

11 their parameters, from the "content" of the various 

12 objects; e.g. the character string (content) of a 
Q 13 text object is separated from the dimensional 

SJ 14 parameters of the object; the image data (content) 

m 15 of a graphic object is separated from its 

%? i 

If 16 dimensional parameters. This allows document 

f*j 17 structures to be defined in a very compact manner 

m 18 and provides the option for content data to be 

^ 19 stored remotely and to be fetched by the system only 

20 when needed . 

y ^ 

22 The internal representation 14 describes the 

23 document and its constituent objects in terms of 

24 "high-level" descriptions. 
25 

2 6 The internal representation data 14 is input to 

27 a parsing and rendering module 18 which generates a 

28 context-specific representation 20 or "view" of the 
2 9 document represented by the internal representation 

30 14. The required view may be of the whole document 

31 or of part(s) (subset (s) ) thereof. The 

32 parser/renderer 18 receives view control inputs 40 
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1 which define the viewing context and any related 

2 temporal parameters of the specific document view 

3 which is to be generated. For example, the system 

4 may be required to generate a zoomed view of part of 

5 a document, and then to pan or scroll the zoomed 

6 view to display adjacent portions of the document. 

7 The view control inputs 40 are interpreted by the 

8 parser /renderer 18 in order to determine which parts 

9 of the internal representation are required for a 

10 particular view and how, when and for how long the 

11 view is to be displayed. 
12 

13 The context-specific representation/view 20 is 

J: 14 expressed in terms of primitive shapes and 

ly 15 parameters. 

W 17 The parser/renderer 18 may also perform 

yj 

s - " . 18 additional pre-processing functions on the relevant 

y 19 parts of the internal representation 14 when 

20 generating the required view 20 of the source 

%i 21 document 10. The view representation 20 is input to 

22 a shape processor module 22 for final processing to 

23 generate a final output 24, in a format suitable for 

24 driving an output device 26 (or multiple output 

25 devices), such as a display device or printer. 
26 

27 The pre-processing functions of the 

28 parser/renderer 18 may include colour correction, 

29 resolution adjustment /enhancement and anti-aliasing. 

30 Resolution enhancement may comprise scaling 

31 functions which preserve the legibility of the 

32 content of objects when displayed or reproduced by 
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the target output device. Resolution adjustment may 




2 


be context-sensitive; e.g. the display resolution of 




3 


particular objects may be reduced while the 




4 


displayed document view is being panned or scrolled 




5 


and increased when the document view is static (as 




6 


described further below in relation to the first 




7 

8 


aspect of the invention) . 
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There may be a feedback path 42 between the 




10 


renderer/parser 18 and the internal representation 




11 


14; e.g. for the purpose of triggering an update of 




12 


the content of the internal representation 14, such 




13 


as in the case where the document 10 represented by 


uf^ 


14 


the internal representation comprises a multi-frame 


%M 


15 


animation . 
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The output representation 20 from the 


!" 


18 


parser/renderer 18 expresses the document in terms 




19 


of "primitive" objects. For each document object, 


h 


20 


the representation 20 preferably defines the object 


Cl 


21 


at least in terms of a physical, rectangular 




22 


boundary box, the actual shape of the object bounded 




23 


by the boundary box, the data content of the object, 




24 


and its transparency. 




25 






26 


The shape processor 22 interprets the 




27 


representation 20 and converts it into an output 




28 


frame format 24 appropriate to the target output 




29 


device 26; e.g. a dot-map for a printer, vector 




30 


instruction set for a plotter, or bitmap for a 




31 


display device. An output control input 44 to the 




32 


shape processor 22 defines the necessary parameters 



for the shape processor 22 to generate output 24 
suitable for a particular output device 26. 

The shape processor 22 preferably processes the 
objects defined by the view representation 20 in 
terms of "shape" (i.e. the outline shape of the 
object), "fill" (the data content of the object) and 
"alpha" (the transparency of the object) , performs 
scaling and clipping appropriate to the required 
view and output device, and expresses the object in 
terms appropriate to the output device (typically in 
terms of pixels by scan conversion or the like, for 
most types of display device or printer) . 

The shape processor 22 preferably includes an 
edge buffer which defines the shape of an object in 
terms of scan-converted pixels, and preferably 
applies anti-aliasing to the outline shape. Anti- 
aliasing is preferably performed in a manner 
determined by the characteristics of the output 
device 26 (i.e. on the basis of the control input 
44), by applying a grey-scale ramp across the object 
boundary. This approach enables memory efficient 
shape-clipping and shape-intersection processes. 

A look-up table may be employed to define 
multiple tone response curves, allowing non-linear 
rendering control (gamma correction) . 

The individual objects processed by the shape 
processor 22 are combined in the composite output 
frame 24. The quality of the final output can also 
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1 be controlled by the user via the output control 

2 input 44. 
3 

4 The shape processor 22 has a multi-stage 

5 pipeline architecture which lends itself to parallel 

6 processing of multiple objects, or of multiple 

7 documents, or of multiple subsets of one or more 

8 document, by using multiple instances of the shape 

9 processor pipeline. The pipeline architecture is 

10 also easily modified to include additional 

11 processing functions (e.g. filter functions) if 

12 required. Outputs from multiple shape processors 22 
q 13 may generate multiple output frames 24 or may be 

J: 14 combined in a single output frame 24. 

Us? 

]=j 16 The system architecture is modular in nature. 

y$ 17 This enables, for example, further document agents 

s 18 to be added as and when required, to deal with 

y 19 additional source file formats. The modular 

M s 20 architecture also allows individual modules such as 

21 the library 16, parser/renderer 18 or shape 

22 processor 22 to be modified or upgraded without 

23 requiring changes to other modules. 
24 

25 The system architecture as a whole also lends 

26 itself to parallelism in whole or in part for 

27 simultaneous processing of multiple input documents 

28 10a, 10b etc. or subsets of documents, in one or 

29 more file formats, via one or more document agents 

30 12, 12a. The integrated, modular nature of the 

31 system allows multiple instances of system modules 

32 to be spawned within a data processing system or 
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1 device as and when required, limited only by 

2 available processing and memory resources. 
3 

4 The potential for flexible parallelism provided 

5 by the system as a whole and the shape processor 22 

6 in particular allows the display path for a given 

7 device to be optimised for available bandwidth and 

8 memory. Display updates and animations may be 

9 improved, being quicker and requiring less memory. 

10 The object/parameter document model employed is 

11 deterministic and consistent. The system is fully 

12 scalable and allows multiple instances of the system 

13 across multiple CPUs. 
14 

15 The parser/renderer 18 and shape processor 22 

16 interact dynamically in response to view control 

17 inputs 4 0 , in a manner which optimises the use of 

18 available memory and bandwidth. This applies 

19 particularly to re-draw functions when driving a 

20 visual display, e.g. when the display is being 

21 scrolled or panned by a user. 
22 

23 Firstly, the system may implement a scalable 

24 deferred re-draw model, in accordance with a first 

25 aspect of the invention, such that the display 

26 resolution of a document view, or of one or more 

27 objects within a view, varies dynamically according 

28 to the manner in which the display is to be 

29 modified. This might typically involve an object 

30 being displayed at reduced resolution whilst being 

31 moved on-screen and being displayed at full 

32 resolution when at rest. The system may employ 



multiple levels of display quality for this purpose. 
Typically, this will involve pre-built, low 
resolution bitmap representations of document 
objects and/or dynamically built and scaled bitmaps, 
with or without interpolation. This approach 
provides a highly responsive display which makes 
best use of available memory/bandwidth. 

Methods embodying this first aspect of the 
present invention are illustrated in Figs. 2A and 
2B. 

When a redraw request is initiated within the 
system, it is necessary for all or part of the 
current frame to be re-rendered and displayed. The 
process of re-rendering the frame may take a 
significant amount of time. 

Referring to Fig. 2A, when a redraw request 100 
is initiated, the output frame is immediately 
updated (102) using one or more reduced resolution 
("thumbnail") bitmap representations of the document 
or parts thereof which are scaled to approximate the 
required content of the redrawn display. In the 
system 8 of Fig. 1, the bitmap representation ( s ) 
employed for this purpose may be pre-built by the 
parser/renderer 18 and stored for use in response to 
redraw requests. This approximation of the redrawn 
display can be generated much more quickly than the 
full re-rendering of the display, providing a 
temporary display while re-rendering is completed. 
In the embodiment of Fig. 2A, the full re-rendering 
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of the display (104) is performed in parallel with 
the approximate redraw 102, and replaces the 
temporary display once it is complete (106). The 
method may include one or more additional 
intermediate updates 108 of the approximate 
temporary display while the full re-rendering 104 is 
completed. These intermediate updates may 
progressively "beautify" the temporary display (i.e. 
provide successively better approximations of the 
final display); e.g. by using better quality scaled 
bitmaps and/or by superimposing vector outlines of 
objects on the bitmap (s). 

The method of Fig. 2A also allows the redraw 
process to be interrupted by a new redraw request 
(110). The full re-rendering process 104 can simply 
be halted and the system processes the new redraw 
request as before. 

Fig. 2B illustrates an alternative embodiment 
in which a redraw request 112 is followed by an 
approximate thumbnail-based redraw 114 as before, 
and the full frame redraw 116 follows in series 
after the approximate redraw (instead of in parallel 
as in Fig. 2A) to generate the final full resolution 
display 118. This process may also be interrupted 
at any stage by a new redraw request. 

The methods of Figs. 2A and 2B may be applied 
to all types of redraw requests, including screen 
re-builds, scrolling, panning and scaling (zooming) . 
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Fig. 3 illustrates a preferred method of 
zooming/scaling a thumbnail bitmap. A basic bitmap 
120 is created and stored by the system at some 
previous stage of document processing as previously 
described. Assuming that the bitmap is required to 
be scaled by some arbitrary factor {e.g. by a factor 
4.4), the basic thumbnail 120 is scaled in two 
stages: first, the thumbnail is scaled by a 
fractional amount (122) corresponding to the final 
scaling factor divided by the whole number part 
thereof (4.4 divided by 4 equals 1.1 in this 
example) , and then by an integer amount (124) 
corresponding to the whole number part of the final 
scaling factor (i.e. x4 in this example). This is 
faster than a single stage zoom of 4.4, at the 
expense of a small increase in memory requirement. 

The scaling operations described above may be 
performed with or without interpolation. Fig. 3 
shows the final zoomed bitmap 124 interpolated to 
provide a resolution of 16 x 16 as compared with the 
original 8x8 bitmap 120. Interpolation may be 
performed using any of a variety of well known 
interpolation methods. 

The ability to process transparent objects is a 
significant feature of the system of Fig. 1. 
However, this necessitates the use of off-screen 
buffering in the shape processor 22 in order to 
assemble a final output frame. Typically, as shown 
in Fig. 4A, a conventional off-screen buffer 130 
will cover an area larger than the immediate display 



19 

1 area, allowing a limited degree of panning/scrolling 

2 within the buffer area, but the entire buffer has to 

3 be re-centred and re-built when the required display 

4 moves outwith these limits. This requires a block- 

5 copy operation within the buffer and redrawing of 

6 the remaining "dirty rectangle" (132) before block- 

7 copying the updated buffer contents to the screen 

8 134 . 
9 

10 In accordance with a second aspect of the 

11 present invention, as illustrated in Fig. 4B, the 

12 efficiency of such buffering processes is improved 
q 13 by defining the buffer content as an array of tiles 

14 136, indexed in an ordered list. Each tile 

|ij 15 comprises a bitmap of fixed size (e.g. 32 x 32 or 64 

Tb' 16 x 64) and may be regarded as a "mini-buffer". When 

SO 17 the required display view moves outwith the buffer 

% 18 area, it is then only necessary to discard those 

tJ 19 tiles which are no longer required, build new tiles 

H 20 to cover the new area of the display and update the 

jt| 21 tile list (138) . This is faster and more efficient 

IM* 22 than conventional buffering processes, since no 

23 block-copying is required within the buffer and no 

24 physical memory is required to be moved or copied. 
25 

26 The tiling scheme described may be used 

27 globally to provide a tilepool for all document and 

28 screen redraw operations. The tiles are used to 

29 cache the document (s) off-screen and allow rapid, 

30 efficient panning and re-centering of views. 
31 
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The use of a tilepool as described also allows 
for more efficient usage of memory and processor 
resources. Fig. 5A shows how conventional off- 
screen buffering methods, involving data blocks 
which have arbitrary, unpredictable sizes, result in 
the fragmentation of memory due to unpredictable 
contiguous block allocation requirements. Blocks of 
memory required by buffering operations are mis- 
matched with processor memory management unit (MMU) 
blocks, so that re-allocation of memory becomes 
inefficient, requiring large numbers of physical 
memory copy operations, and cache consistency is 
impaired. By using tiles of fixed, predetermined 
size, memory requirements become much more 
predictable, so that memory and processor resources 
may be used and managed much more efficiently, 
fragmentation may be unlimited without affecting 
usability and the need for memory copy operations 
may be substantially eliminated for many types of 
buffering operations. Ideally, the tile size is 
selected to correspond with the processor MMU block 
size . 

Fig. 5C illustrates a preferred scheme for 
managing tiles within the tilepool. Tile number 
zero is always reserved for building each new tile. 
Once a new tile has been built, it is re-numbered 
using the next available free number (i.e. where the 
tilepool can accommodate a maximum of n tiles the 
number of tile addresses allocated is restricted to 
n-1) . In the event of a tilepool renumbering 
failure, when the tilepool is full and there are no 
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more free tiles, the new tile 0 is written directly 
to screen and a background process (thread) is 
initiated for garbage collection (e.g. 
identification and removal of "aged" tiles) and/or 
allocation of extra tile addresses. This provides 
an adaptive mechanism for dealing with resource- 
allocation failures . 

The tiling scheme described lends itself to 
parallel processing, as illustrated in Fig. 6. 
Processing of a set of tiles can be divided between 
multiple parallel processes (e.g. between multiple 
instances of the shape processor 22 of Fig. 1). For 
example, a set of tiles 1-20 can be divided based on 
the screen positions of the tiles so that the 
processing of tiles 1-10 is handled by one processor 
WASP-A and the processing of tiles 11-20 is handled 
by a second processor WASP-B. Accordingly, if a 
redraw instruction requires tiles 1-3, 7-9 and 12-14 
to be redrawn, tiles 2-4 and 7-9 are handled by 
WASP-A and tiles 12-14 by WASP-B. Alternatively, 
the set of tiles can be divided based on the 
location of the tiles in a tile memory map, dividing 
the tile memory into memory A for processing by 
WASP-A and memory B for processing by WASP-B. 

The tiling scheme described facilitates the use 
of multiple buffering and off-screen caching. It 
also facilitates interruptable re-draw functions 
(e.g. so that a current re-draw may be interrupted 
and a new re-draw initiated in response to user 
input) , efficient colour/display conversion and 



dithering, fast 90 degree (portrait/landscape) 
rotation of whole display in software, and reduces 
the redraw memory required for individual objects. 
Tiling also makes interpolated bitmap scaling faster 
and more efficient. It will also be appreciated 
that a system such as that of Fig. 1 may employ a 
common tilepool for all operating system/GUI and 
application display functions of a data processing 
system. 

It will be understood that the tiling methods 
of the second aspect of the invention may 
advantageously be combined with the redraw methods 
of the first aspect of the invention. 

In accordance with a third aspect of the 
present invention, the processing of a document 
involves dividing each page of the document to be 
viewed into zones (this would involve interaction of 
the renderer/parser 18 and shape processor 22 in the 
system 8 of Fig. 1), as illustrated in Fig. 7. Each 
zone A, B, C, D has associated with it a list of all 
objects 1-8 contained within or overlapping that 
zone. Re-draws can then be processed on the basis 
of the zones, so that the system need only process 
objects associated with the relevant zones affected 
by the re-draw. This approach facilitates parallel 
processing and improves efficiency and reduces 
redundancy. The use of zones also facilitates the 
use of the system to generate different outputs for 
different display devices (e.g. for generating a 
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1 composite/mosaic output for display by an array of 

2 separate display screens) . 
3 

4 As illustrated in Fig. 8 f without the use of 

5 zoning, any screen update relating to the shaded 

6 area 142 would require each of the eight objects 1 

7 to 8 to be checked to see whether the bounding box 

8 of the object intersects the area 142 in order to 

9 determine whether that object needs to be plotted. 

10 With zoning, it is possible to determine firstly 

11 which zones intersect the area 142 (zone D only in 

12 this example) , secondly, which objects intersect the 

13 relevant zone(s) (object 2 only in this case), and 
^ 14 then it is only necessary to check whether the 

yj 15 bounding boxes of those objects which intersect the 

%1 16 relevant zone(s) also intersect the area 142. In 

ffiS 17 many cases, this will greatly reduce the overhead 

J" 18 involved in extracting and comparing objects with 

W 19 the area 142 of interest. 

| 20 

21 It will be appreciated that zoning of this type 

M 

H : 22 may be of little or no benefit in some circumstances 

23 (e.g. in the extreme case where all objects on a 

24 page intersect all zones of the page) ; the 

25 relationship between the zone size and the typical 

26 object size may be significant in this respect. For 

27 the purposes of determining the nature of any zoning 

28 applied to a particular page, an algorithm may be 

29 employed to analyse the page content and to 

30 determine a zoning scheme (the number, size and 

31 shape of zones) which might usefully be employed for 

32 that page. However, for typical page content, which 



will commonly include many small, locally clustered 
objects, an arbitrary division of the page into 
zones is likely to yield significant benefits. 

The zoning and tiling schemes described above 
are independent in principle but may be combined 
advantageously; i.e. zones may correlate with one or 
more tiles. Again this facilitates parallelism and 
optimises use of system resources. 

Referring again to Fig. 1, the system 
preferably employs a device-independent colour 
model, suitably a luminance/chrominance model such 
as the CIE L*a*b* 1976 model. This reduces 
redundancy in graphic objects, improves data 
compressibility and improves consistency of colour 
output between different output devices. Device- 
dependent colour correction can be applied on the 
basis of the device-dependent control input 44 to 
the shape processor 22. 

Fig. 1 shows the system having an input end at 
which the source bytestream is received and an 
output end where the final output frame 24 is output 
from the system. However, it will be understood 
that the system may include intermediate inputs and 
outputs at other intermediate stages, such as for 
fetching data content or for saving/converting data 
generated in the course of the process. 

Digital document processing systems in 
accordance with the fourth aspect of the present 
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1 invention may be incorporated into a variety of 

2 types of data processing systems and devices, and 

3 into peripheral devices, in a number of different 

4 ways. 
5 

6 In a general purpose data processing system 

7 (the "host system"), the system of the present 

8 invention may be incorporated alongside the 

9 operating system and applications of the host system 

10 or may be incorporated fully or partially into the 

11 host operating system. 
12 

13 For example, the system of the present 

Sf 14 invention enables rapid display of a variety of 

|jj 15 types of data files on portable data processing 

J 16 devices with LCD displays without reguiring the use 

CO 17 of browsers or application programs. This class of 

e " 18 data processing devices requires small size, low 

y 19 power processors for portability. Typically, this 

20 requires the use of advanced RISC-type core 

%i 21 processors designed into ASICs (application specific 

22 integrated circuits) , in order that the electronics 

23 package is as small and highly integrated as 

24 possible. This type of device also has limited 

25 random access memory and typically has no non- 
26 volatile data store (e.g. hard disk) . Conventional 

27 operating system models, such as are employed in 

28 standard desktop computing systems (PCs), require 

29 high powered central processors and large amounts of 

30 memory in order to process digital documents and 

31 generate useful output, and are entirely unsuited 

32 for this type of data processing device. In 
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1 particular, conventional systems do not provide for 

2 the processing of multiple file formats in an 

3 integrated manner. By contrast, the present 

4 invention may utilise common processes and pipelines 

5 for all file formats, thereby providing a highly 

6 integrated document processing system which is 

7 extremely efficient in terms of power consumption 

8 and usage of system resources. 
9 

10 The system of the present invention may be 

11 integrated at the BIOS level of portable data 

12 processing devices to enable document processing and 
f%. 13 output with much lower overheads than conventional 

14 system models. Alternatively, the invention may be 

Id 15 implemented at the lowest system level just above 

%£■ 16 the transport protocol stack. For example, the 

50 17 system may be incorporated into a network device 

~*~ 18 (card) or system, to provide in-line processing of 

'^' J 19 network traffic (e.g. working at the packet level in 

^ 20 a TCP/IP system) . 

51 21 

Ip^ 22 In a particular device, the system of the 

23 invention is configured to operate with a 

24 predetermined set of data file formats and 

25 particular output devices; e.g. the visual display 

26 unit of the device and/or at least one type of 

27 printer. 
28 

29 Examples of portable data processing devices 

30 which may employ the present system include 

31 "palmtop" computers, portable digital assistants 

32 (PDAs, including tablet-type PDAs in which the 
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primary user interface comprises a graphical display 
with which the user interacts directly by means of a 
stylus device) , internet-enabled mobile telephones 
and other communications devices , etc. 

The system may also be incorporated into low 
cost data processing terminals such as enhanced 
telephones and "thin" network client terminals (e.g. 
network terminals with limited local processing and 
storage resources) , and "set-top boxes" for use in 
interactive/internet-enabled cable TV systems. 

When integrated with the operating system of a 
data processing system, the system of the present 
invention may also form the basis of a novel 
graphical user interface (GUI) for the operating 
system (OS) . Documents processed and displayed by 
the system may include interactive features such as 
menus, buttons, icons etc. which provide the user 
interface to the underlying functions of the 
operating system. By extension, a complete OS/GUI 
may be expressed, processed and displayed in terms 
of system "documents". The OS/GUI could comprise a 
single document with multiple "chapters". 

The system of the present invention may also be 
incorporated into peripheral devices such as 
hardcopy devices (printers and plotters), display 
devices (such as digital projectors) , networking 
devices, input devices (cameras, scanners etc.) and 
also multi-function peripherals (MFPs) . 
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When incorporated into a printer, the system 
may enable the printer to receive raw data files 
from the host data processing system and to 
reproduce the content of the original data file 
correctly, without the need for particular 
applications or drivers provided by the host system. 
This avoids the need to configure a computer system 
to drive a particular type of printer. The present 
system may directly generate a dot-mapped image of 
the source document suitable for output by the 
printer (this is true whether the system is 
incorporated into the printer itself or into the 
host system) . Similar considerations apply to other 
hardcopy devices such as plotters. 

When incorporated into a display device, such 
as a projector, the system may again enable the 
device to display the content of the original data 
file correctly without the use of applications or 
drivers on the host system, and without the need for 
specific configuration of the host system and/or 
display device. Peripheral devices of these types, 
when equipped with the present system, may receive 
and output data files from any source, via any type 
of data communications network. 

From the foregoing, it will be understood that 
the system of the present invention may be "hard- 
wired; e.g. implemented in ROM and/or integrated 
into ASICs or other single-chip systems, or may be 
implemented as firmware (programmable ROM such as 
flashable ePROM) , or as software, being stored 
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1 locally or remotely and being fetched and executed 

2 as required by a particular device. 
3 

4 Improvements and modifications may be 

5 incorporated without departing from the scope of the 

6 present invention. 



W 

y i 



